Software Verification

When a technology reaches a higher level of maturity, its development begins to diversify and to differentiate. In 1885 engineers were happy to build the first car powered by a gasoline engine. Today we see a whole spectrum of vehicles ranging from city cars, limousines, off-road vehicles, sports cars, buses, trucks, etc., that share some basic technologies but greatly differ in details. Software Verification has entered this phase of diversification and we need to start this exposee with a rough classification. On the top level we distinguish between model verification and program verification. By model verification we understand the formal analysis and modelling of systems, algorithm or software at a high level of abstraction using mathematical notions like sets, sequences, relations. Representatives of this category are for instance the B-method, the Z approach, or abstract state machines (ASM). With these, often some concept of refinement is involved, that formalizes the transition from an abstract model to a more concrete model. The goal of these methodologies may be characterized by the label: correctness by construction. Another set of methods use temporal logic model checking (e.g., Promela, CSP). Methods and tools in this category support system development but do not look into the actual implementing code. They are good for eliminating design flaws at a very early stage. Biased by our own interests and competence we will say no more on this kind of verification and concentrate on program verification. This approach presupposes the existence of executable program code together with a specification. Usually the specifications come as annotations in the code written in a specification language closely related to the programming language in use. Before we can comment on the usability of program verification, we need to have an idea to what use it shall be put. Here is a first coarse classification of the use cases of formal methods in programming: